fix(runtime): release native objects on the runtime's thread - #560

Current behavior

JS can run on any thread that holds the isolate's Locker: a JS function passed to dispatch_async on a background queue runs there, for example. A garbage collection triggered on that thread runs the wrappers' finalizers on it too, and they release the native objects inline. A view, a CATransaction, or a block capturing one can therefore be deallocated off the main thread, which UIKit and Core Animation do not tolerate and which can crash the app. __releaseNativeCounterpart called from such a thread has the same problem.

New behavior

Which releases move. A native release moves to the runtime's thread when two things hold:

• it happens off that thread;
• the object first reached JS on that thread.

ObjCDataWrapper and BlockWrapper record the second at construction. Each runtime records its own thread (pthread_self(), next to its run loop) where it binds its event loop, and the check compares it with the calling thread through the isolate's runtime. Several runtimes can share a thread.

Which stay put.

• Objects that first reached JS on another thread are still released where the collection runs. A background queue's own objects are not moved onto the main thread.
• Collection adapters still release inline, because their -dealloc retires the wrapper.

How the handover works.

• The release ([object release] or Block_release, from a finalizer or __releaseNativeCounterpart) goes into a per-isolate queue, drained by one event loop task per batch.
• JS-side disposal is unchanged and still immediate: the wrapper is retired, the Instances entry erased and the internal field cleared at once.
• The queue is plain containers with no mutex or atomics. Finalizers, __releaseNativeCounterpart, wrapper creation, the drain task and teardown all hold the isolate's Locker. The only lock left is the event loop's own, once per batch.
• Teardown drains the queue inline before and after the disposal walk, since the event loop has stopped by then.

Re-wrapping a queued object. A new wrapper for an object whose release is still queued takes that release over as its own retain instead of retaining again. That keeps exact the retain counts the JS-extended classes' retain/release swizzle reads. If native code retained the object in the meantime, the new wrapper is protected on the spot, since the swizzle had no wrapper to protect then.

Approximations.

• "First reached JS" is a stand-in for "created on": an object created on main but first handed to JS by background code counts as background-born. Touching UIKit objects from a background thread is already outside UIKit's rules.
• A worker's runtime thread is the worker's own thread, not the main thread.

On the runtime's thread nothing changes except a thread-id compare per ObjC or block wrapper creation and disposal.

Documented in docs/knowledge/v8-resurrecting-finalizers.md ("Which thread releases the native object").

Testing

New specs in GCFinalizerTests.js. Both use a JS-extended TNSApi instance owned only by its wrapper, which records NSThread.isMainThread from methodCalledInDealloc; __collect() runs in a dispatch_async block on a background queue.

• Created on main: the dealloc runs on main. With the deferral disabled this spec fails (Expected $[0] = false to equal true).
• Created inside the background block: the dealloc stays on the background thread.

Full suite, 0 failures (1869 specs).